Patrick Elliott wrote:
> that, "If you are going to store that stuff in an array, lets at least 
> assign the array to something that "looks" like its part of the object, 
> and not some separate entity." In other words, if you are going to apply 
> 10 transforms to object Z, then *make that array* part of the Z object, 
> *at least* from the perspective of the coder.

Why not just allow arrays that can be indexed by objects? Then you can 
have multiple arrays of transformations per object. You could have a 
"walking" array, indexed by body part, where each element is an array of 
transforms to be applied at each step of the walk cycle, then a 
"running" array indexed by body parts ....

Walking gets
object arm = cylinder(....)
object leg = blob(...)
translate(arm, walk[arm].translates[frame % 6])
rotate(arm, walk[arm].rotates[frame % 6])
translate(leg, walk[leg].mytranslate[frame % 6])

Running gets
object arm = cylinder(....)
object leg = blob(...)
translate(arm, run[arm].translates[frame % 6])
rotate(arm, run[arm].rotates[frame % 6])
translate(leg, run[leg].translates[frame % 6])

 > That way you can tell
> "what" they belong to by simply referencing the object they belong to, 
> not some arbitrary array that has no association, save that you just 
> happen to use it for that.

Arbitrary associations is the meat of programming. There's no real 
reason that a translation "belongs" more to an object than to an 
animation cycle than to a room of the house you're modeling.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message